NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/456

Internet Message Format | 1996-08-06 | 3.9 KB

Path: tbj.dec.com!diamond
From: [e-mail] (Norman Diamond)
Newsgroups: comp.std.c
Subject: Re: sizeof(char) ~= sizeof(float)
Date: 28 Feb 1996 08:07:26 GMT
Organization: Digital Equipment Corporation Japan , Tokyo
Message-ID: <4h12fu$[e-mail]>
References: <[e-mail]> <4gr3d1$[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Norman Diamond)
NNTP-Posting-Host: jit533.tbj.dec.com

In article <[e-mail]>, [e-mail] (Tanmoy Bhattacharya) writes:
>In article <4gr3d1$[e-mail]>
>[e-mail] (Norman Diamond) writes:
>>Rumor has it that Technical Corrigendum 2 will change the standard so that
>>unsigned char cannot have any holes.  Signed char will still be allowed to
>>have holes, and char will still have to behave either as unsigned char (no
>>holes) or as signed char (identical holes).

>What happens to the requirement that positive signed integral values
>have to have the same representation as the corresponding unsigned
>integral value? Coupled with the requirement of pure binary
>representation [...] it seems to say that if unsigned char can't have
>holes, neither can signed char

ANSI Classic section 3.1.2.5, freshly unpacked in this month's new office,
page 24 lines 3 to 5:  "The range of nonnegative values of a signed
integer type is a subrange of the corresponding unsigned integer type,
and the representation of the same value in each type is the same."
If unsigned char can hold the value 255 but signed char cannot, there is
no violation of the "subrange" requirement and there is no signed
representation to be matched.  Even if unsigned char can hold the value
65535 but signed char cannot hold values 65535 or 255, no problem.

>unless whether a certain bit contributes to the value or not depends on the
>sign bit; I assume such `holes' are allowed?

I have a vague impression that this kind of hole is not allowed.  A hole
is either part of the representation of the type or it is not.

>I was assuming that the rumored TC2 interpretation will be adopted.
>The argument is that in
>  float x, y;
>  unsigned char *xx=(void*)&x, *yy=(void*)&y;
>copying (or comparing) sizeof(float) unsigned chars from xx to yy must
>manage to copy (or compare) x from y.

Or more precisely:
   float x, y;
   unsigned char (*xx)[sizeof(float)]=(void*)&x,
                 (*yy)[sizeof(float)]=(void*)&y;
   *yy = *xx;
Yes, if the rumored TC2 interpretation is adopted, I think this will
have to work.

>Whether or not `char' can have holes, if there are say two
>representations of 0 (sign-magnitude / one's complement etc.) a copy
>of char can change one representation to the other.

I think so.

[Without, or before, TC2]:
>>If you use memcpy or possibly if you play tricks with union types, you can
>>force it to copy all the bits.

>This was a free-standing implementation, and memcpy may be absent.

I think suitable union types would still work.  But now I wonder, if the
programmer knows that the objects are floats, why not just assign floats?

[Regardless of TC2, I think]:
>(In a hosted implementation, as all read/write is done as if through
>getc/putc which handles unsigned char values, and binary files written
>out must be read back unchanged, the situation is impossible).

Actually there's already a problem here.  If there are two representations
of 0 but all read/write is done as if through functions which convert
between int and unsigned char, it is impossible to read some stuff back
unchanged.  I hope a DR was submitted about this a few years ago.
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer